fix(detectors): framework detector fp/fn corpus pass - #341
Conversation
csrfmiddlewaretoken is a hidden form body field django templates render, never a header, so marking it HeaderOnly meant it could never match and a real django form page (csrf field plus csrftoken cookie) went undetected.
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #341 +/- ##
=======================================
Coverage ? 60.11%
=======================================
Files ? 81
Lines ? 6884
Branches ? 0
=======================================
Hits ? 4138
Misses ? 2454
Partials ? 292 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
pr summary5 files changed (+285 -14)
|
87db7cb to
dfde6d6
Compare
version extraction only ever searched the response body, so
header-shaped patterns like ASP.NET's "X-AspNet-Version: x.y.z" or
Flask's "Werkzeug/x.y.z" Server header could never match even when the
detector itself fired off that same header. add
ExtractVersionFromResponse, which also searches canonical header
lines, and point aspnet and flask at it. fix the aspnet header regexes
to match case-insensitively, since Go canonicalizes header names
("X-AspNet-Version" becomes "X-Aspnet-Version") and the old literal
pattern never matched the canonical form.
promote the ad-hoc probe/sweep scratch tests used to find these defects into a proper regression file: for each fix, assert both the real-product positive still detects and the prose/other-product negative does not, plus a sweep of unrelated pages against every registered detector.
dfde6d6 to
86cb567
Compare
vmfunc
left a comment
There was a problem hiding this comment.
the (?i:X-AspNet-Version) catch in version.go is the good one. http.Header canonicalizes to X-Aspnet-Version so the old case-sensitive literal could never have matched off a real response, and the comment spells out exactly why. django csrfmiddlewaretoken going HeaderOnly->body is right too, that's a hidden form field, never a header.
one thing, not blocking: bumping _next/static to 0.6 pushed the denominator to 1.7, so NEXT_DATA alone is now 0.5/1.7 = 0.294, conf lands at 0.485 and it stops self-detecting (it used to at 0.333). in practice both markers co-occur double-quoted so real next pages still fire, but NEXT_DATA is the most definitive next marker and you gave ng-version and astro self-clearing weight in this same pass, so it's odd to leave this one under the line. bump it to ~0.6 while you're in there.
rest is clean. in.
several framework detectors keyed on signatures that either dropped valid
signal or diluted a real match. django's csrfmiddlewaretoken pattern was
marked HeaderOnly even though it's a hidden form body field, so it never
matched. aspnet's weak .aspx/.ashx/.asmx path-extension signatures diluted
confidence below threshold on a response carrying only header markers;
they're dropped, and version extraction for aspnet/flask now also
searches canonical header text so header-shaped versions
(X-AspNet-Version, Werkzeug's Server header) are found.
a pinned fp/fn corpus test (hardening_test.go) locks in both the positive
and prose-false-positive case for each of the affected detectors.